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Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS 
Abstract 
The IETF has standardized the Transparent Interconnection of Lots of 
Links (TRILL) protocol, which provides transparent Layer 2 forwarding 
using encapsulation with a hop count and IS-IS link state routing. 
This document specifies the data formats and code points for the 
IS-IS extensions to support TRILL. 
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2. 


Introduction 


The IETF has standardized the TRILL protocol [RFC6325], which 
provides transparent Layer 2 forwarding using encapsulation with a 
hop count and link state routing. TRILL provides optimal pair-wise 
forwarding without configuration, safe forwarding even during periods 
of temporary loops, and support for multipathing of both unicast and 
multicast traffic as well as supporting VLANs. Intermediate Systems 
(ISs) implementing TRILL can incrementally replace IEEE [802.10-2005] 
bridges. 


This document, in conjunction with [RFC6165], specifies the data 
formats and code points for the IS-IS [ISO-10589] [RFC1195] 
extensions to support TRILL. 


1. Conventions Used in This Document 


The terminology and acronyms defined in [RFC6325] are used herein 
with the same meaning. 


Additional acronyms used in this document are: 
IIH - IS-IS Hello 


IS - Intermediate System (for this document, all relevant 
intermediate systems are RBridges) 


NLPID - Network Layer Protocol Identifier 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


TLV and Sub-TLV Extensions to IS-IS for TRILL 


This section, in conjunction with [RFC6165], specifies the data 
formats and code points for the TLVs and sub-TLVs added to IS-IS to 
support the TRILL standard. Information as to the number of 
occurrences allowed, such as for a TLV in a PDU or set of PDUs or for 
a sub-TLV in a TLV, is provided in Section 5. 


1. The Group Address TLV 


The Group Address (GADDR) TLV, IS-IS TLV type 142, is carried only in 
an LSP PDU and carries sub-TLVs that in turn advertise multicast 
group listeners. Section 2.1.1 below specifies a sub-TLV that 
advertises listeners by MAC address. It is anticipated that 
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additional sub-TLVs for additional address types such as IP addresses 


will be specified in other documents. 


constitute a new series of sub-TLV types 


GADDR has the following format: 


+-+-+-+-+-+-+-+- 
| Type=GADDR-TLV 


+ 
| 
-+-+-+-+-+-+-+-+ 
| 
+ 


-+-+-+-+-+-+-+- 


sub-TLVs.. 


-+-+-+-+-+-+-+- 


TLV Type, 


+ 

| Length 
+ 

+ 

o Type: 

o Length: 


o sub-TLVs: 


2.1.1. 


The Group MAC Address 


set to 


(1 byt 


(1 byt 


-+-+-+-+-+-+-+-+ 


+-+-+-+-+-+-+-+-+ 


GADDR-TLV 142. 


e) 


e) 


variable depending on the sub-TLVs carried. 


The sub-TLVs under GADDR 
(see Section 5.2). 


The Group Address TLV value consists of sub-TLVs 
formatted as described in [RFC5305]. 


The Group MAC Address Sub-TLV 


within the GADDR TLV. In 
listeners as specified in 
following format: 


+—-+-+-+-+-+-+-+-+ 
| Type=GMAC-ADDR | 


RE 


RE 


-+-+ 


-+-+ 


+ — + — + — + — + — 4+ — + — + 


Eastlake 


sv | 


sv | 


-+-+ 


-+-+ 


, et 


=+- 


+ 


+ 


al. 


-+-+-+-+-+-+-+-+ 
Length 
-+-+-+-+-+-+-+-+-+-+-+-+- 


Topology-ID 


-+-+-+-+-+-+-+-+-+-+-+-+- 


VLAN ID 


+ 


+ 


-+-+-+-+-+-+-+-+-+ 
Num Group Recs 


-+-+ 


-+-+-+- 


(GMAC-ADDR) 


TRILL, 


(1 byt 
(1 byt 
+-+-+-+ 
| (2 byt 
+-+-+-+ 
| (2 byt 
+-+-+-+ 
(1 byt 
+-+-+-+-+-+-+-+ 
RECORDS (1) 
+-+-+-+-+-+-+-+ 
+-+-+-+-+-+-+-+ 
RECORDS (N) 
+-+-+-+-+-+-+-+ 


Standards Track 


sub-TLV is sub-TLV type number 1 
it is used to advertise multicast 
Section 4.5.5 of [RFC6325]. 


It has the 
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-+-+ 


-+-+ 


-+-+ 


+ — + — + — + — + — ++ 


-+-+ 


o Type: 


TRILL Use of IS-IS 


each group record is of the form: 


+-+-+-+-+-+ 
of Sources | 


(1 byte) 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 


+-+-+-+-+-+ 


+-+-+-+-+-+ 


+-+-+-+-+-+ 


+-+-+-+-+-+ 


+ 


+ 


+ 


+ 


Group Address (6 bytes) 
-+-+-+-+-+-+-+-+-+-+-+-+ 
Source 1 Address ( 
-+-+-+-+-+-+-+-+-+-+-+-+-+- 
( 
+ 


+-+-+-+- 
Source 2 Address 6 bytes) 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
Source M Address (6 bytes) 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 


GADDR sub-TLV type, set to 1 (GMAC-ADDR). 


o Length: Variable, minimum 5. 


o RESV: Reserved. 
ignored on receipt. 


o Topology-ID: 


4-bit fields that MUST be sent as 


This field is not used in TRILL, where 


zero and ignored on receipt, but is included for us 
technologies. 


o VLAN ID: 
subsequent MAC addresses in this sub-TLV, 


VLAN is specified. 


July 2011 


+-+-+-+-+-+ 


+-+-+-+-+-+ 


+-+-+-+-+-+ 


zero and 


it is sent as 
e by other 


This carries the 12-bit VLAN identifier for all 
or the value zero if no 


o Number of Group Records: A 1-byte integer that is the number of 
group records in this sub-TLV. 


o Group Record: Each group record carries the number of sources. It 
then has a 48-bit multicast address followed by 48-bit source MAC 


addresses. 


If the sources do not fit in a single sub-TLV, the 


same group address may be repeated with different source addresses 
in another sub-TLV of another instance of the Group Address TLV. 


2.2. Multi-Topology-Aware Port Capability Sub-TLVs 


TRILL makes use of the Multi-Topology-Aware Port Capability 


(MT-PORT-CAP) 


TLV as specified in [RFC6165]. 


The remainder of this 


section specifies the sub-TLVs that TRILL uses the MT-PORT-CAP TLV to 
transport. 


Eastlake 


LA 
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2.2.1. The Special VLANs and Flags Sub-TLV 


In TRILL, a Special VLANs and Flags (VLAN-Flags) sub-TLV is carried 
in every IIH PDU. It has the following format: 


+-+-+-+-+-+-+-+-+ 


| Type | (1 byte) 
4+-+-4-4+-4+-4+-4+-4+-+ 

| Length | (1 byte) 
4+--------------- 4+--------------- + 

| Port ID | (2 bytes) 
4------------------------------- + 

| Sender Nickname | (2 bytes) 
4+--+--4+--+--+------------------- + 
|AF|Ac|vM|By | Outer. VLAN | (2 bytes) 
HO + 

|TR|R |R |R Desig.VLAN | (2 bytes) 
PH + 


o Type: sub-TLV type, set to MT-PORT-CAP VLAN-FLAGs sub-TLV 1. 
o Length: 8. 


o Port ID: An ID for the port on which the enclosing TRILL IIH PDU 
is being sent as specified in [RFC6325], Section 4.4.2. 


o Sender Nickname: If the sending IS is holding any nicknames as 
discussed in [RFC6325], Section 3.7, one MUST be included here. 
Otherwise, the field is set to zero. This field is to support 
intelligent end stations that determine the egress IS (RBridge) 
for unicast data through a directory service or the like and that 
need a nickname for their first hop to insert as the ingress 
nickname to correctly format a TRILL encapsulated data frame. See 
[RFC6325], Section 4.6.2, point 8. 


o Outer.VLAN: A copy of the 12-bit outer VLAN ID of the TRILL IIH 
frame containing this sub-TLV when that frame was sent, as 
specified in [RFC6325], Section 4.4.5. 


o Desig.VLAN: The 12-bit ID of the designated VLAN for the link, as 
specified in [RFC6325], Section 4.2.4.2. 


o AF, AC, VM, BY, and TR: These flag bits have the following 


meanings when set to one, as specified in the listed section of 
[RFC6325]: 
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Bit Section Meaning if bit is one 

AF 4.4.2 Originating IS believes it is appointed forwarder 
for the VLAN and port on which the containing IIH 
PDU was sent. 

AC 4.9.1 Originating port configured as an access port 
(TRILL traffic disabled). 

VM 4.4.5 VLAN mapping detected on this link. 

BY 4.4.2 Bypass pseudonode. 

TR 4.9.1 Originating port configured as a trunk port (end- 


station service disabled). 
o R: Reserved bit. MUST be sent as zero and ignored on receipt. 
2.2.2. Enabled-VLANs Sub-TLV 


The optional Enabled-VLANs sub-TLV specifies the VLANs enabled for 
end station service at the port of the originating IS on which the 
Hello was sent, as specified in [RFC6325], Section 4.4.2. It has the 
following format: 


-+-+-+-+-+-+-+-+ 
Type | (1 byte) 
-+-+-+-+-+-+-+-+ 
Length | (1 byte) 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
RESV | Start VLAN ID | (2 bytes) 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
VLAN bit-map.... 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


+ — + — + — + — + 


O 


Type: sub-TLV type, set to MT-PORT-CAP Enabled-VLANs sub-TLV 2. 
o Length: Variable, minimum 3. 


o RESV: 4 reserved bits that MUST be sent as zero and ignored on 
receipt. 


o Start VLAN ID: The 12-bit VIAN ID that is represented by the high 
order bit of the first byte of the VLAN bit-map. 
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VLAN bit-map: The highest order bit indicates the VLAN equal to 
the start VLAN ID, the next highest bit indicates the VLAN equal 
to start VLAN ID + 1, continuing to the end of the VLAN bit-map 
field. 


If this sub-TLV occurs more than once in a Hello, the set of enabled 
VLANS is the union of the sets of VLANs indicated by each of the 
Enabled-VLAN sub-TLVs in the Hello. 


PAMAN 


Appointed Forwarders Sub-TLV 


The DRB on a link uses the Appointed Forwarders sub-TLV to inform 
other ISs on the link that they are the designated VLAN-x forwarder 
for one or more ranges of VLAN IDs as specified in Section 4.2.4 of 
[RFC6325]. It has the following format: 


+—+—4+—4+—4+—4+ 


+-+-+-+-+-+-+-+ 


Type | (1 byte) 
+-+-+-+-+-+-+-+ 
Length | (1 byte) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Appointment Information (1) | (6 bytes) 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Appointment Information (N) | (6 bytes) 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


where each appointment is of the form: 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Appointee Nickname | (2 bytes) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
RESV | Start .VLAN | (2 bytes) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
RESV | End. VLAN | (2 bytes) 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Type: sub-TLV type, set to MT-PORT-CAP AppointedFwrdrs sub-TLV 3. 
Length: 64n bytes, where there are n appointments. 


Appointee Nickname: The nickname of the IS being appointed a 
forwarder. 


RESV: 4 bits that MUST be sent as zero and ignored on receipt. 
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o Start.VLAN, End.VLAN: These fields are the VLAN IDs of the 
appointment range, inclusive. To specify a single VLAN, the 
VLAN’s ID appears as both the start and end VLAN. As specified in 
Section 4.4 of [RFC6325], appointing an IS forwarder on a port for 
a VLAN not enabled on that port has no effect. 


An IS’s nickname may occur as appointed forwarder for multiple VLAN 
ranges by occurrences of this sub-TLV within the same or different MT 
Port Capability TLVs within an IIH PDU. 


2.3. Sub-TLVs for the Router Capability TLV 


The Router Capability TLV is specified in [RFC4971]. All of the sub- 
sections of this Section 2.3 below specify sub-TLVs that can be 
carried in the Router Capability TLV for TRILL. 


2.3.1. The TRILL Version Sub-TLV 


The TRILL Version (TRILL-VER) sub-TLV indicates the maximum version 
of the TRILL standard supported. By implication, lower versions are 
also supported. If this sub-TLV is missing, the originating IS only 
supports the base version of the protocol [RFC6325]. 


-+-+-+-+-+-+-+- 
Type 
-+-+-+-+-+-+-+- 
Length 
-+-+-+-+-+-+-+- 
Max-version 
-+-+-+-+-+-+-+- 


(1 byte) 
(1 byte) 


(1 byte) 


+ —+—+—+ 
+—+—+—+ 


o Type: Router Capability sub-TLV type, set to 13 (TRILL-VER). 
o Length: 1. 


o Max-version: Set to maximum version supported. 
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PAPAG 


The Nickname Sub-TLV 


The Nickname (NICKNAME) Router Capability sub-TLV carries information 
about the nicknames of the originating IS, along with information 
about its priority to hold those nicknames as specified in [RFC6325], 
Section 3.7.3. Multiple instances of this sub-TLV may be carried. 


+- 


+-+-+-+-+-+-+-+ 


|Type = NICKNAME | (1 byte) 
4+-+-4-4+-4-4-4-4+ 
Length | 1 byte) 


+—+—+—4+—4+ 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
NICKNAME RECORDS 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 


PAF 
H 
+~ + 


+-4+-4-4-4-4-4-4-4-4+-4-4-4-4+-4+-4-4-4-4+-4+-4-4-4-4-4+-4+-4-4-4-4-4-4 
NICKNAME RECORDS 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 


PAZ 
Z 
+7 + 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


where each nickname record is of the form: 


+— + — + — + 


+-+-+-+-+-+-+-+ 
Nickname.Pri (1 byte) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Tree Root Priority | (2 byte) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Nickname | (2 bytes) 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Type: Router Capability sub-TLV type, set to 6 (NICKNAME). 
Length: 5*N, where N is the number of nickname records present. 


Nickname.Pri: An 8-bit unsigned integer priority to hold a 
nickname as specified in Section 3.7.3 of [RFC6325]. 


Tree Root Priority: This is an unsigned 16-bit integer priority to 
be a tree root as specified in Section 4.5 of [RFC6325]. 


Nickname: This is an unsigned 16-bit integer as specified in 
Section 3.7 of [RFC6325]. 


Eastlake, et al. Standards Track [Page 10] 


RFC 6326 TRILL Use of IS-IS July 2011 


2.3.3. The Trees Sub-TLV 


Each IS providing TRILL service uses the TREES sub-TLV to announce 
three numbers related to the computation of distribution trees as 
specified in Section 4.5 of [RFC6325]. Its format is as follows: 


+-+-+-+-+-+-+-+-+ 


|Type = TREES | (1 byte) 
+-+-+-+-+-+-+-+-+ 

| Length | (1 byte) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Number of trees to compute | (2 byte) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Maximum trees able to compute | (2 byte) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Number of trees to use | (2 byte) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


o Type: Router Capability sub-TLV type, set to 7 (TREES). 
o Length: 6. 


o Number of trees to compute: An unsigned 16-bit integer as 
specified in Section 4.5 of [RFC6325]. 


o Maximum trees able to compute: An unsigned 16-bit integer as 
specified in Section 4.5 of [RFC6325]. 


o Number of trees to use: An unsigned 16-bit integer as specified in 
Section 4.5 of [RFC6325]. 


2.3.4. The Tree Identifiers Sub-TLV 


The tree identifiers (TREE-RT-IDs) sub-TLV is an ordered list of 
nicknames. When originated by the IS that has the highest priority 
tree root, it lists the distribution trees that the other ISs are 
required to compute as specified in Section 4.5 of [RFC6325]. If 
this information is spread across multiple sub-TLVs, the starting 
tree number is used to allow the ordered lists to be correctly 
concatenated. The sub-TLV format is as follows: 
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2: 


Pba 


+-+-+-+-+-+-+-+-+ 
| Type=TREE-RT-IDs | (1 byte) 
+-+-+-+-+-+-+-+-+ 
| Length | (1 byte) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|Starting Tree Number | (2 bytes) 
LALA 

Nickname (K-th root) | (2 bytes) 
LALA 

Nickname (Kt1 - th root) | (2 bytes) 
LALA 

Nickname (...) | 
LALA 


+— +—+—+ 


o Type: Router Capability sub-TLV type, set to 8 (TREE-RT-IDs). 
o Length: 2 + 2*n, where n is the number of nicknames listed. 


o Starting Tree Number: This identifies the starting tree number of 
the nicknames that are trees for the domain. This is set to 1 for 
the sub-TLV containing the first list. Other Tree-Identifiers 
sub-TLVs will have the number of the starting list they contain. 
In the event a tree identifier can be computed from two such sub- 
TLVs and they are different, then it is assumed that this is a 
transient condition that will get cleared. During this transient 
time, such a tree SHOULD NOT be computed unless such computation 
is indicated by all relevant sub-TLVs present. 


o Nickname: The nickname at which a distribution tree is rooted. 
3.5. The Trees Used Identifiers Sub-TLV 


This Router Capability sub-TLV has the same structure as the Tree 
Identifiers sub-TLV specified in Section 2.3.4. The only difference 
is that its sub-TLV type is set to 9 (TREE-USE-IDs), and the trees 
listed are those that the originating IS wishes to use as specified 
in [RFC6325], Section 4.5. 


3.6. Interested VLANs and Spanning Tree Roots Sub-TLV 


The value of this Router Capability sub-TLV consists of a VLAN range 
and information in common to all of the VLANs in the range for the 
originating IS. This information consists of flags, a variable 
length list of spanning tree root bridge IDs, and an appointed 
forwarder status lost counter, all as specified in the sections of 
[RFC6325] listed with the respective information items below. 
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In the set of LSPs originated by an IS, the union of the VLAN ranges 
in all occurrences of this sub-TLV MUST be precisely the set of VLANs 
for which the originating IS is appointed forwarder on at least one 
port, and the VLAN ranges in multiple VLANs sub-TLVs for an IS MUST 
NOT overlap unless the information provided about a VLAN is the same 
in every instance. However, as a transient state these conditions 
may be violated. If a VLAN is not listed in any INT-VLAN sub-TLV for 
an IS, that IS is assumed to be uninterested in receiving traffic for 
that VLAN. If a VLAN appears in more than one INT-VLAN sub-TLV for 
an IS with different information in the different instances, the 
following apply: 


- If those sub-TLVs provide different nicknames, it is 
unspecified which nickname takes precedence. 

- The largest appointed forwarder status lost counter is used. 

- The originating IS is assumed to be attached to a multicast 
IPv4 router for that VLAN if any of the INT-VLAN sub-TLVs 
assert that it is so connected and similarly for IPv6 multicast 
router attachment. 

- The root bridge lists from all of the instances of the VLAN for 
the originating IS are merged. 


To minimize such occurrences, wherever possible, an implementation 
SHOULD advertise the update to an interested VLAN and Spanning Tree 
Roots sub-TLV in the same LSP fragment as the advertisement that it 
replaces. Where this is not possible, the two affected LSP fragments 
should be flooded as an atomic action. An IS that receives an update 
to an existing interested VLAN and Spanning Tree Roots sub-TLV can 
minimize the potential disruption associated with the update by 
employing a hold-down timer prior to processing the update so as to 
allow for the receipt of multiple LSP fragments associated with the 
same update prior to beginning processing. 


The sub-TLV layout is as follows: 


+-+-+-+-+-+-+-+-+ 

|Type = INT-VLAN| (1 byte) 

+++ ho ++ + ++ 

| Length | (1 byte) 

a a 

| Nickname | (2 bytes) 
LO 

| Interested VLANS | (4 bytes) 
a a ee totot-4-+ 

| Appointed Forwarder Status Lost Counter | (4 bytes) 
dh + hh q Ph + + + + + + + ho ++ to t—+ 

| Root Bridges | (6*n bytes) 
IN 
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o Type: Router Capability sub-TLV type, set to 10 (INT-VLAN). 

o Length: 10 + 6*n, where n is the number of root bridge IDs. 

o Nickname: As specified in [RFC6325], Section 4.2.4.4, this field 
may be used to associate a nickname held by the originating IS 
with the VLAN range indicated. When not used in this way, it is 


set to zero. 


o Interested VLANS: The Interested VLANs field is formatted as shown 


below. 

0 1 2 3 4 - 15 16 - 19 20 - 31 
4+----+----4----+4----+------------ 4+---------- 4+------------ + 
| Ma | m6 | R | R | VLAN.start | RESV | VLAN.end | 
PA AHA 4+---------- 4+------------ + 


- M4, M6: These bits indicate, respectively, that there is an 
IPv4 or IPv6 multicast router on a link for which the 
originating IS is appointed forwarder for every VLAN in the 
indicated range as specified in [RFC6325], Section 4.2.4.4, 
item 5.1. 


- R, RESV: These reserved bits MUST be sent as zero and are 
ignored on receipt. 


- VLAN.start and VLAN.end: This VLAN ID range is inclusive. A 
range of one VLAN ID is indicated by setting them both to that 
VLAN ID value. 


o Appointed Forwarder Status Lost Counter: This is a count of how 
many times a port that was appointed forwarder for the VLANs in 
the range given has lost the status of being an appointed 
forwarder as discussed in Section 4.8.3 of [RFC6325]. It is 
initialized to zero at an IS when the zeroth LSP sequence number 
is initialized. No special action need be taken at rollover; the 
counter just wraps around. 


o Root Bridges: The list of zero or more spanning tree root bridge 
IDs is the set of root bridge IDs seen for all ports for which the 
IS is appointed forwarder for the VLANs in the specified range as 
discussed in [RFC6325], Section 4.9.3.2. While, of course, only 
one spanning tree root could be seen on any particular port, there 
may be multiple ports in the same VLAN connected to different 
bridged LANs with different spanning tree roots. 
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An INT-VLAN sub-TLV asserts that the information provided (multicast 
router attachment, appointed forwarder status lost counter, and root 
bridges) is the same for all VLANs in the range specified. If this 
is not the case, the range MUST be split into subranges meeting this 
criteria. It is always safe to use sub-TLVs with a "range" of one 
VIAN ID, but this may be too verbose. 


2.3.7. The VLAN Group Sub-TLV 
The VLAN Group Router Capability sub-TLV consists of two or more VLAN 
IDs as specified in [RFC6325], Section 4.8.4. This sub-TLV indicates 
that shared VLAN learning is occurring at the announcing IS between 


the listed VLANs. It is structured as follows: 


+-+-+-+-+-+-+-+-+ 


| Type=VLAN-GROUP | (1 byte) 
+-+-+-+-+-+-+-+-+ 

| Length | (1 byte) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| RESV | Primary VLAN ID | (2 bytes) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| RESV | Secondary VLAN ID | (2 bytes) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| more Secondary VLAN IDs ... (2 bytes each) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


o Type: Router Capability sub-TLV type, set to 14 (VLAN-GROUP). 


o Length: 4 + 2*n, where n is the number of secondary VLAN ID 
fields, which may be zero. 


o RESV: a 4-bit field that MUST be sent as zero and ignored on 
receipt. 


o Primary VLAN ID: This identifies the primary VLAN ID. 


o Secondary VLAN ID: This identifies a secondary VLAN in the VLAN 
Group. 


o more Secondary VLAN IDs: zero or more byte pairs, each with the 
top 4 bits as a RESV field and the low 12 bits as a VLAN ID. 


2.4. MTU Sub-TLV of the Extended Reachability TLV 
The MTU sub-TLV is used to optionally announce the MTU of a link as 


specified in [RFC6325], Section 4.2.4.4. It occurs within the 
Extended Reachability TLV (type 22). 
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+-+-+-+-+-+-+-+-+ 
| Type = MTU | (1 byte) 

+-+-+-+-+-+-+-+-+ 

| Length | (1 byte) 

+-+-+-+-+-+-+-+-+ 

|F| Reserved | (1 byte) 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| MTU | (2 bytes) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Type: Extended Reachability sub-TLV type, set to MTU sub-TLV 28. 


O 


o Length: 3. 


o F: Failed. This bit is a one if MTU testing failed on this link 
at the required campus-wide MTU. 


o Reserved: 7 bits that MUST be sent as zero and ignored on receipt. 


o MTU: This field is set to the largest successfully tested MTU size 
for this link, or zero if it has not been tested, as specified in 
Section 4.3.2 of [RFC6325]. 


2.5. TRILL Neighbor TLV 


The TRILL Neighbor TLV is used in TRILL IIH PDUs (see Section 4.1 
below) in place of the IS Neighbor TLV, as specified in Section 
4.4.2.1 of [RFC6325] and in [RFC6327]. The structure of the TRILL 
Neighbor TLV is as follows: 


+-+-+-+-+-+-+-+-+ 
| Type | 
+-+-+-+-+-+-+-+-+ 
| Length | (1 byte) 
+ 
| 
+ 


+ 

+ -+-+-+-+-+-+-+-+- 
| Neighbor RECORDS 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
+ 

+ 


+o+ 
H 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
Neighbor RECORDS 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 


+o+ 
Z 
+7 + 
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The information present for each neighbor is as follows: 


+-+-+-+-+-+-+-+-+ 
|F| RESV | (1 bytes) 
+ 


E 

| MTU | (2 bytes) 

La a a AA n. n totot-t-t-4-+ 

| MAC Address | (6 bytes) 
La a a to tot-t-t-4-4+ 


o Type: TLV Type, set to TRILL Neighbor TIV 145. 


o Length: 1 + 9*n, where n is the number of neighbor records which 
may be zero. 


o S: Smallest flag. If this bit is a one, then the list of 
neighbors includes the neighbor with the smallest MAC address 
considered as an unsigned integer. 


o L: Largest flag. If this bit is a one, then the list of neighbors 
includes the neighbor with the largest MAC address considered as 
an unsigned integer. 


o RESV: These 7 bits are reserved use and MUST be sent as zero and 
ignored on receipt. 


o F: failed. This bit is a one if MTU testing to this neighbor 
failed at the required campus-wide MTU (see [RFC6325], Section 
And Le): 


o MTU: This field is set to the largest successfully tested MTU size 
for this neighbor or to zero if it has not been tested. 


o MAC Address: The MAC address of the neighbor as in the IS Neighbor 
TLV (6). 


As specified in [RFC6327] and Section 4.4.2.1 of [RFC6325], all MAC 
addresses may fit into one TLV, in which case both the S and L flags 
would be set to one in that TLV. If the MAC addresses don’t fit into 
one TLV, the highest MAC address in a TRILL Neighbor TLV with the L 
flag zero MUST also appear as a MAC address in some other TRILL 
Neighbor TLV (possibly in a different TRILL IIH PDU). Also, the 
lowest MAC address in a TRILL Neighbor TLV with the S flag zero MUST 
also appear in some other TRILL Neighbor TLV (possibly in a different 
TRILL IIH PDU). If an RBridge believes it has no neighbors, it MUST 
send a TRILL Neighbor TLV with an empty list of neighbor RECORDS, 
which will have both the S and L bits on. 
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3s 


The MTU PDUs 


Two PDUs are added to IS-IS, the MTU-probe and MTU-ack PDUs. They 
are used to optionally determine the MTU on a link between ISs as 
specified in [RFC6325], Section 4.3.2. 


The MTU PDUs have the IS-IS PDU common header (up through the Maximum 
Area Addresses byte) with two new PDU Type numbers, one each, as 
listed in Section 6. They also have a 20-byte common fixed MTU PDU 
header as shown below. 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| PDU Length | (2 bytes) 

PARAAN +++ 
| Probe ID (6 bytes) | 
+-+-+-+-+-+- +++ +-+-+ 
| Probe Source ID (6 bytes) | 
Paa a a +++ 4-4-4 
| Ack Source ID (6 bytes) | 
E 1-4-4 


As with other IS-IS PDUs, the PDU length gives the length of the 
entire IS-IS packet starting with and including the IS-IS common 
header. 


The Probe ID field is an arbitrary 48-bit quantity set by the IS 
issuing an MTU-probe and copied by the responding IS into the 
corresponding MTU-ack. For example, an IS creating an MTU-probe 
could compose this quantity from a port identifier and probe sequence 
number relative to that port. 


The Probe Source ID is set by an IS issuing an MTU-probe to its 
System ID and copied by the responding IS into the corresponding 
MTU-ack. 


The Ack Source ID is set to zero in MTU-probe PDUs. An IS issuing an 
MTU-ack sets this field to its System ID. 


The TLV area follows the MTU PDU header area. This area MAY contain 
an Authentication TLV and MUST be padded to the exact size being 
tested with the Padding TLV. Since the minimum size of the Padding 
TLV is 2 bytes, it would be impossible to pad to exact size if the 
total length of the required information bearing fixed fields and 
TLVs added up to 1 byte less than the desired length. However, the 
length of the fixed fields and substantive TLVs for MTU PDUs will be 
quite small compared with their minimum length (minimum 1470-byte MTU 
on an 802.3 link, for example), so this will not be a problem. 
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4. Use of Existing PDUs and TLVs 


The sub-sections below provide details of TRILL use of existing PDUs 
and TLVs. 


4.1. TRILL IIH PDUs 


The TRILL IIH PDU is the variation of the LAN IIH PDU used by the 
TRILL protocol. Section 4.4 of the TRILL standard [RFC6325] 
specifies the contents of the TRILL IIH and how its use in TRILL 
differs from Layer 3 LAN IIH PDU use. The adjacency state machinery 
for TRILL neighbors is specified in Section 4.4 of [RFC6325] and in 
[RFC6327]. 


In a TRILL IIH PDU, the IS-IS common header and the fixed PDU Header 
are the same as a Level 1 LAN IIH PDU. The Maximum Area Addresses 
octet in the common header MUST be set to 0x01. 


The IS-IS Neighbor TLV (6) is not used in a TRILL IIH and is ignored 
if it appears there. Instead, TRILL IIH PDUs use the TRILL Neighbor 
TLV (see Section 2.5). 

4.2. Area Address 


TRILL uses a fixed zero Area Address as specified in [RFC6325], 
Section 4.2.3. This is encoded in a 4-byte Area Address TLV (1) as 


follows: 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| 0x01, Area Address Type | (1 byte) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| 0x02, Length of Value | (1 byte) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| 0x01, Length of Address | (1 byte) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| 0x00, zero Area Address | (1 byte) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

4.3. Protocols Supported 
NLPID 0xC0 has been assigned to TRILL [RFC6328]. A Protocols 


Supported TLV (129, [RFC1195]) including that value MUST appear in 
TRILL IIH PDUs and LSP number zero PDUs. 
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5. TANA Considerations 


TANA has allocated the existing registry code points listed in 
Section 5.1 and created two new registries with the initial contents 
as described in Section 5.2. 


5.1. Allocations from Existing Registries 


This document specifies two new IS-IS TLV types -- namely, the Group 
Address TLV (GADDR-TLV, type 142) and the TRILL Neighbor TLV (type 
145). The PDUs in which these TLVs are permitted for TRILL are shown 
in the table below along with the section of this document where they 
are discussed. The final "NUMBER" column indicates the permitted 
number of occurrences of the TLV in their PDU, or set of PDUs in the 
case of LSP, which in these two cases is "*" indicating that the TLV 
MAY occur 0, 1, or more times. 


IANA registered these two code points in the IANA IS-IS TLV registry 
(ignoring the "Section" and "NUMBER" columns, which are irrelevant to 
that registry). 


Section TLV# IIH LSP SNP NUMBER 


142 = X = 


GADDR-TLV 1 
5 145 X = = 


Zi. 
TRILL Neighbor TLV 2 
This document specifies eleven new sub-TLVs from existing sub-TLV 
sequences -- namely, VLAN-FLAGS, Enabled-VLANs, AppointedFwrdrs, 
TRILL Version (TRILL-VER), NICKNAME, TREES, TREE-RT-IDs, 
TREE-USE-IDs, INT-VLAN, VLAN-GROUP, and MTU. The TLVs in which these 
sub-TLVs occur are shown in the table below along with the section of 
this document where they are discussed. 


Those sub-TLVs with an "X" in the column labeled "MT Port Capabil." 
are sub-TLVs of TLV 143 [RFC6165], the MT-PORT-CAP-TIV. Those sub- 
TLVs with an "X" in the column labeled "Router Capabil." are sub-TLVs 
of TLV 242, the IS-IS Router CAPABILITY TLV. Those sub-TLVs with an 
"X" in the column labeled "Extended IS Reach" are sub-TLVs of TLV 22, 
the Extended IS reachability TLV. 


The final "NUM" column indicates the permitted number of occurrences 
of the sub-TLV cumulatively within all occurrences of their TLV in 
that TLV’s carrying PDU (or set of PDUs in the case of LSP), as 
follows: 
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0-1 = MAY occur zero or one times. If it occurs more than once, 
results are unspecified. 
1 “ MUST occur exactly once. If absent, the PDU is ignored. If 
it occurs more than once, results are unspecified. 
* = MAY occur 0, 1, or more times. 


The values in the "Section" and "NUM" columns are irrelevant to the 
IANA sub-registries. 


Section sub- MT Port Router Extended NUM 
TLV# Capabil. Capabil. IS Reach 

VLAN-FLAGS 2o21 T X = - al 
Enabled-VLANs 262.02 2 X = - kj 
AppointedFwrdrs 2.2.3 3 X = - E 
NICKNAME 2.3.2 6 = X = x 
TREES 2.3.3 4 - X - 0-1 
TREE-RT-IDs 2.3.4 8 = X = 
TREE-USE-IDs 2.3.5 9 = X - 
INT-VLAN 2.3.6 10 = X z 
TRILL-VER 231 13 = X - 0-1 
VLAN-GROUP 2.3.7 14 = X = a 
MTU 2.4 28 = - X 0-1 


5.2. New Sub-Registries Created 


This document creates two new IS-IS PDUs -- namely, the MTU-PROBE-PDU 
and MTU-ACK-PDU, as described in Section 3. IANA assigned new PDU 
types to these PDUs and reflect them in a newly created PDU registry 
(see Appendix A). 


MTU-PROBE-PDU PDU Number: 23 
MTU-ACK-PDU PDU Number: 28 


IANA created a new sub-TLV IS-IS sub-registry for sub-TLVs within the 
Group Address (GADDR) TLV and specified an initial sub-TLV within 


that registry -- namely, the Group MAC Address (GMAC-ADDR) sub-TLV 
(1). The GMAC-ADDR sub-TLV may occur 0, 1, or more times in a GADDR 
TLV. 


The initial sub-registry is shown below. 
Registry Name: IS-IS Group Address Type Codes for TLV 10 


Reference: This document 
Registration Procedures: Expert Review [RFC5226] 
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7. 


7. 


Registry: 
Value Group Address Type Code Reference 
0 Reserved This document 
1 GMAC-ADDR This document 
2-254 Unassigned This document 
255 Reserved This document 


Security Considerations 


For general TRILL protocol security considerations, see the TRILL 
base protocol standard [RFC6325]. 


This document raises no new security issues for IS-IS. IS-IS 
security may be used to secure the IS-IS messages discussed here. 

See [RFC5304] and [RFC5310]. Even when IS-IS authentication is used, 
replays of Hello packets can create denial-of-service conditions; see 
[RFC6039] for details. These issues are similar in scope to those 
discussed in Section 6.2 of [RFC6325], and the same mitigations may 


apply. 
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Appendix A. 


TRILL Use of IS-IS 


Initial IS-IS PDU Registry 


July 2011 


The following is the suggested initial IS-IS PDU registry before 
MTU-PROBE-PDU and MTU-ACK-PDU, 
document as REFERENCE: 


Registry Name: 
Reference: 


IS-IS PDUs 


This document 


Registration Procedures: 


MNEMONIC 


Unassigned 


P 


L1-LAN-HELLO-PDU 
L2-LAN-HELLO-PDU 
P2P-HELLO-PDU 


L1-LSP-PDU 
Unassigned 
L2-LSP-PDU 
Unassigned 
L1-CSNP-PDU 
L2-CSNP-PDU 
L1-PSNP-PDU 
L2-PSNP-PDU 
Unassigned 
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IETF Review [RFC5226] 


DU# 


0-14 
1:5 

16 

Lv 

18 

19 

20 
21-23 
24 

25 

26 

27 
28-31 
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